Using quality models in software package selection

The growing importance of commercial off-the-shelf software packages requires adapting some software engineering practices, such as requirements elicitation and testing, to this emergent framework. Also, some specific new activities arise, among which selection of software packages plays a prominent role. All the methodologies that have been proposed recently for choosing software packages compare user requirements with the packages' capabilities. There are different types of requirements, such as managerial, political, and, of course, quality requirements. Quality requirements are often difficult to check. This is partly due to their nature, but there is another reason that can be mitigated, namely the lack of structured and widespread descriptions of package domains (that is, categories of software packages such as ERP systems, graphical or data structure libraries, and so on). This absence hampers the accurate description of software packages and the precise statement of quality requirements, and consequently overall package selection and confidence in the result of the process. Our methodology for building structured quality models helps solve this drawback.Peer ReviewedPostprint (published version

An empirical study on the use of i* by non-technical stakeholders: the case of strategic dependency diagrams

Early phases of information systems engineering include the understanding of the enterprise’s context and the construction of models at different levels of decomposition, required to design the system architecture. These time-consuming activities are usually conducted by relatively large teams, composed of groups of non-technical stakeholders playing mostly an informative role (i.e. not involved in documentation and even less in modelling), led by few experienced technical consultants performing most of the documenting and modelling effort. This paper evaluates the ability of non-technical stakeholders to create strategic dependency diagrams written with the i* language in the design of the context model of a system architecture, and find out which difficulties they may encounter and what the quality of the models they build is. A case study involving non-technical stakeholders from 11 organizational areas in an Ecuadorian university held under the supervision and coordination of the two authors acting as consultants. The non-technical stakeholders identified the majority of the dependencies that should appear in the case study’s context model, although they experienced some difficulties in declaring the type of dependency, representing such dependencies graphically and applying the description guidelines provided in the training. Managers were observed to make more mistakes than other more operational roles. From the observations of these results, a set of methodological advices were compiled for their use in future, similar endeavours. It is concluded that non-technical stakeholders can take an active role in the construction of the context model. This conclusion is relevant for both researchers and practitioners involved in technology transfer actions with use of i*.Peer ReviewedPostprint (author's final draft

Lessons learned on the use of i* by non-technical users

Enterprise Architecting activities, particularly the mapping from business strategies to information systems architectures, are time-consuming activities usually conducted by relatively large teams, composed of groups of nontechnical stakeholders playing mostly an informative role, led by few experienced technical consultants performing most of the documenting and modelling effort. Lately, several works have been reported that propose and use i* to support these modelling activities. In spite of this increasing adoption and experiences in different domains, there exists little work in relation to the practical use of i* by non-technical stakeholders and the ability that the notation may provide them to become more proactive in system modelling activities. We present here 10 lessons learned in a study conducted in an Ecuadorian University to gain empirical evidence in relation to the use of i* by non-technical stakeholders.Peer ReviewedPostprint (published version

Towards the definition of a quality model for mail servers

The paper presents an approach for building a Mail Server Quality Model, based on the ISO/IEC software quality standard. We start by defining the mail system domain to be used as general framework and the relevant technologies involved. Then a general overview of the ISO/IEC standard is given. The basic steps, the relevant considerations and criteria used to select the appropriated subcharacteristics and quality attributes are also presented. The selected attributes are categorized under the six ISO/IEC quality characteristics conforming the model. Finally some case studies requirements and two commercial mail server tools are used to evaluate the model.Postprint (published version

Building strategic enterprise context models with i*: a pattern-based approach

Modern enterprise engineering (EE) requires deep understanding of organizations and their interaction with their context. Because of this, in early phases of the EE process, enterprise context models are often built and used to reason about organizational needs with respects to actors in their context and vice versa. However, far from simple, this task is usually cumbersome because of knowledge and communication gaps among technical personnel performing EE activities and their administrative counterparts. In this paper, we propose the use of strategic patterns expressed with the i* language aimed to help bridging this gap. Patterns emerged from several industrial applications of our DHARMA method, and synthesize knowledge about common enterprise strategies, e.g. CRM. Patterns have been constructed based on the well-known Porter’s model of the 5 market forces and built upon i* strategic dependency models. In this way technical and administrative knowledge and skills are synthesized in a commonly agreeable framework. The use of patterns is illustrated with an industrial example in the telecom field.Postprint (author’s final draft

On the use of i* for architecting hybrid systems: a method and an evaluation report

The architectural definition of hybrid software systems is a challenging problem that demands to reconcile stakeholders’ strategic needs and components marketplace, whilst defining an appropriate set of services. We have defined a method called DHARMA based on the i* framework. The goal of this paper is to present an experience report about the use of i* in large-scale projects. We provide two different viewpoints: the viewpoint of the stakeholder and the viewpoint of the modeller. Apart from general lessons learned, we also provide some insights about the use of i* in the specific context of architecting hybrid systems using DHARMA.Peer ReviewedPostprint (author’s final draft

A quality-model-based approach for describing and evaluating software packages

Selection of software packages from user requirements is a central task in software engineering. Selection of inappropriate packages may compromise business processes and may interfere negatively in the functioning of the involved organization. Success of package selection is endangered because of many factors, one of the most important being the absence of structured descriptions of both package features and user quality requirements. In this paper, we propose a methodology for describing quality factors of software packages using the ISO/IEC quality standard as a framework. Following this standard, relevant attributes for a specific software domain are identified and structured as a hierarchy, and metrics for them are chosen. Software packages in this domain can then be described in a uniform and comprehensive way. Therefore, selection of packages can be ameliorated by transforming user quality requirements into requirements expressed in terms of quality model attributes. We illustrate the approach by presenting, in some depth, a quality model for the mail server domain.Peer ReviewedPostprint (published version

Descubriendo la arquitectura de sistemas de software híbridos: un enfoque basado en Modelos i*

La mayoría de sistemas de software modernos se construyen integrando componentes de diversa naturaleza (comerciales, código libre, componentes legados, etc.), formando arquitecturas híbridas. La construcción de este tipo de sistemas se caracteriza por la adquisición de diversos componentes a proveedores externos a la organización que se integran con algún software hecho a medida. La correcta aplicación de este enfoque requiere la temprana identificación de los servicios que el sistema deberá brindar y su agrupación en dominios atómicos (los actores del sistema), que serán posteriormente remplazados de una manera “oportunista”, por los componentes más apropiados, independientemente de su naturaleza y origen. En este artículo abordamos este aspecto y proponemos un método basado en la utilización de modelos i*, que permite identificar los actores del sistema y su estructuración en una arquitectura de partida. El método es ilustrado con un caso práctico en una empresa de telecomunicaciones.Peer ReviewedPostprint (published version

A framework for selecting workflow tools in the context of composite information systems

When an organization faces the need of integrating some workflow-related activities in its information system, it becomes necessary to have at hand some well-defined informational model to be used as a framework for determining the selection criteria onto which the requirements of the organization can be mapped. Some proposals exist that provide such a framework, remarkably the WfMC reference model, but they are designed to be appl icable when workflow tools are selected independently from other software, and departing from a set of well-known requirements. Often this is not the case: workflow facilities are needed as a part of the procurement of a larger, composite information syste m and therefore the general goals of the system have to be analyzed, assigned to its individual components and further detailed. We propose in this paper the MULTSEC method in charge of analyzing the initial goals of the system, determining the types of components that form the system architecture, building quality models for each type and then mapping the goals into detailed requirements which can be measured using quality criteria. We develop in some detail the quality model (compliant with the ISO/IEC 9126-1 quality standard) for the workflow type of tools; we show how the quality model can be used to refine and clarify the requirements in order to guarantee a highly reliable selection result; and we use it to evaluate two particular workflow solutions a- ailable in the market (kept anonymous in the paper). We develop our proposal using a particular selection experience we have recently been involved in, namely the procurement of a document management subsystem to be integrated in an academic data management information system for our university.Peer ReviewedPostprint (author's final draft

Determining criteria for selecting software components: lessons learned

Software component selection is growing in importance. Its success relies on correctly assessing the candidate components' quality. For a particular project, you can assess quality by identifying and analyzing the criteria that affect it. Component selection is on the suitability and completeness of the criteria used for evaluation. Experiences from determining criteria for several industrial projects provide important lessons. For a particular selection process, you can organize selection criteria into a criteria catalog. A CC is built for a scope, which can be either a domain (workflow systems, mail servers, antivirus tools, and so on) or a category of domains (communication infrastructure, collaboration software, and so on). Structurally, a CC arranges selection criteria in a hierarchical tree-like structure. The higher-level selection criteria serve to classify more concrete selection criteria, usually allowing some overlap. They also serve to leverage the CC.Peer ReviewedPostprint (published version